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Description 

MMS MESSAGE TRANSFER METHOD AND SYSTEM 

The present invention relates to a method and a system for 
transferring messages. 

5 These types of methods or systems are typically used in mobile radio 
devices . 

The world's most widespread mobile radio system GSM (Global system 
for Mobile Communications) , in addition to providing voice 
telephony, offers the option of sending or receiving short messages 
10 of up to 160 characters in length. This service is known as SMS 
(Short Message Service) . 

For mobile radio systems of the next generation (2.5G, 3G) such as 
UMTS (Universal Mobile Telecommunications system) , a multimedia- 
capable variant of a mobile message service is known. With this 

15 message service messages with multimedia contents, known as MMS 
(Multimedia Messaging Service) messages and abbreviated in this 
document to MMS, are sent. By contrast with SMS, MMS messages are 
not restricted purely to text content. In addition it will be 
possible to format texts in accordance with individual taste as well 

20 as to embed audio and video content into a message. 

MMS are described in detail In Technical Specifications TS 22.140 
Version 5.1.0, Release 5 and TS 23.140 Version 5.3.0, Release 5 of 
the 3rd Generation Partnership Project (3GPP) . 

Figure 1 shows a known MMS network architecture with an MMS User 
25 Agent A (MMS UA A) and an MMS User Agent B (MMS UA B) . MMS UA A or 
MMS UA B is an application, for example on a mobile radio terminal 
or on a device connected to a mobile radio terminal, for example a 
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laptop or similar, which can implement MMS . Figure 1 further shows 
two MMS service provider environments MMSE SP A and MMSE SP B 
(Multimedia Messaging Service Environment) , two network elements MMS 
RL A and MMS RL B (MMS Relay/Server) . MMS RL A and MMS RL B are 
5 network elements which make MMS functionalities available to the 

user agents MMS UA A or . MMS UA B within the area of responsibility 
MMSE SP A or MMSE SP B. 

Problems with this known MMS network architecture arise however when 
the network architecture is assembled from components from different 
manufacturers or components with a different functional scope. If 
for example an MMS service provider wishes to operate a number of 
MMS network elements MMS RL A, MMS RL B made by different 
manufacturers with different ranges of functions in their area of 
responsibility MMSE SP A or. MMSE SP B, they must ensure, if a 
particular functionality is demanded for an MMS, for example on 
sending, relaying between two MMS service providers or delivery, 
that an MMS is only processed in the service environment by those 
network elements which support the functionalities demanded. With 
many functionalities there is also the need for an MMS sent in 
response to a previously received original MMS to be processed by 
exactly the same network elements which have already processed the 
original MMS . 

Thus the object of the present invention is to provide a method and 
a system for transmission of messages through which a network 
25 provider can dynamically expand his network architecture at any time 
by new network elements from different manufacturers or by 
components with a different functional scope, without having to run 
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the risk of a service being processed by a network element which 
does not support the desired functionality. 

The object is achieved by a method for transmission of messages and 
a system for transmission of messages with the features of the 
5 independent claims. Developments of the present invention are 
produced by the dependent claims. 

The method features the following steps: 

- Transmission of a message from a first message service provider to 
a second message service provider, 

10 and 

- Evaluation of the message at the second message service provider 

. The message contains at least a first header field which features 
a reference to at least one network element of the first message 
service provider which was involved in the processing of the 

15 message. The messages are preferably MMS messages In these MMS 

messages header fields can be introduced for explicit referencing of 
network elements. Thus for example, on relaying of an MMS message 
between two MMS service providers and on delivery of an MMS message, 
a reference to that network element within the MMS service 

20 environment of the MMS service provider of the recipient or 
references to those network elements within the MMS network 
environments of the two MMS service providers which were involved in 
the processing of the MMS message can be transmitted along with the 
message. The present invention however also includes referencing of 

25 other network elements. 



Preferably the message is transmitted from the second message 
service provider to a network element outside the service 
environment, where the message contains at least a second header 
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field which features a reference to at least one network element of 
the second message service provider which was involved in processing 
the message. The network element outside the service environment is 
preferably a terminal outside the MMSE service environment. 

5 The message further preferably contains, on transmission from the 
second message service provider to the network element outside a 
service environment, the first header field which features a 
reference to at least one network element of the first message 
service provider which was involved in the processing of the 
10 message. 

In a further embodiment the present invention the message is 
returned by the network element outside the service environment via 
the second message service provider to the first message service 
provider, with the reference (s) set in each case from the first 
15 and/or second header field being resolved in the return step. 

The present invention is preferably used in a GSM/GPRS 

(Global System for Mobile Communications/General Packet Radio 
Service) and/or UMTS network. However use in other networks is also 
conceivable . 

20 In a preferred embodiment of the present invention the reference 

features a return path specification. The reference contained in an 
MMS can be used in possible replies to the MMS for explicitly 
addressing a specific network element for further processing of a 
reply MMS. The referencing of a network element is made possible by 

25 the introduction of a first and/or of a second header field. It can 
thus be ensured that an MMS is only relayed to those network 
elements for processing which support a particular functionality 
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which is required. For resolving the references from the first and 
second header field defined above for the individual return steps a 
third and a fourth header field can be introduced. 

In a further embodiment of the present invention the transferred 
5 message is evaluated after arrival at the second message service 
provider from a switching node. The switching node is preferably 
what is known as a router, i.e. a switching network computer. All 
MMS which arrive at an MMS network environment are first directed to 
the switching node. In a preferred embodiment the message contains 
10 the functionality of the message in at least one header field. This 
allows the switching node to decide on the network element for which 
the MMS is suitable since this supports the functionality demanded. 

In a further embodiment of the present invention the switching node 
defines as a function of a header field on the network elements at a 
15 second message service provider to which the message will be 

relayed. After the evaluation of the header field by the network 
node the network node decides on the network element within the area 
of responsibility of the MMS service provider to which this MMS will 
be directed for further processing. 

20 In a preferred embodiment of the present invention the switching 
node is embodied as an self-contained network element. 

In a further preferred embodiment of the present invention the 
switching node is integrated into a relaying means. The relaying 
means can be a network element such as for example a so-called "MMS 
25 RelayServer/", i.e. a network computer for relaying MMS. 
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The object presented at the start is also achieved by a system for 
transmitting messages featuring means for transmission of a message 
from a first message service provider to a second message service 
provider and means for evaluating the message in the second message 
5 service provider, with the message containing at least a first 
header field which features a reference to at least one network 
element of the first message service provider which was involved in 
the processing of the message. 

The present invention further relates to a mobile radio terminal 
10 and/or a transceiver for use in an inventive method and/or in an 
inventive system . 

The invention is explained in greater detail below, with reference 
to the enclosed drawings, on the basis of exemplary embodiments. The 
features shown in the drawings and also the features already 
15 described above can be of importance for the invention not only in 

the said combination but also individually or in other combinations. 
The diagrams show: 

Figure 1 a schematic diagram of a known network architecture; 
Figure 2 a schematic diagram of a exemplary embodiment of a network 
20 architecture with an MMS switching node and a number of 

MMS network elements; 
Figure 3 a schematic diagram of a exemplary embodiment of a network 

architecture with an MMS switching node and MMS network 

elements ; 

25 Figure 4 a schematic diagram of an exemplary embodiment of a 
network architecture; 
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Figure 5 a schematic diagram of a exemplary embodiment of a network 
architecture for sending an MMS with reply charge 
recording; 

Figure 6 a schematic diagram of a exemplary embodiment of a network 
5 architecture on dispatch of a reply MMS; 

Figure 7 a flowchart representing the transmission of an MMS; and 
Figure 8 a flowchart representing the transmission of an MMS in 
accordance with the WAP standard. 

Figure 1 shows an MMS network architecture in accordance with the 
10 prior art and has already been described in the introduction of the 
description . 

Figure 2 shows an exemplary embodiment of an MMS network 
architecture. A network environment MMSE SP A of a first network 
service provider A and a network environment MMSE SP B of a second 

15 network service provider are shown. The MMSE SP A comprises a 

switching node MMS RO A and three separate network elements MMS RL 
Al, MMS RL A2 and MMS RL A3. The switching node MMS RO A is 
connected to a user agent MMS UA A. The second network environment 
MMSE SP B comprises a network element MMS RL B . In the exemplary 

20 embodiment it is assumed that the MMS service provider A has 

gradually expanded his network environment MMSE SP A with different 
network elements MMS RL A of different manufacturers or with 
different functional scopes. It is further assumed that the network 
element MMS RL A3 supports the newest MMS version and is equipped 

25 with particular functionalities while the two other network elements 
MMS RL Al and MMS RL A2 only handle the MMS basic functionalities. 
The choice of a specific network element in the network environment 
of the MMS service provider is made by means of the centrally 
arranged switching node MMS RO A which is responsible for the 

30 distribution of all MMS arriving in the area of responsibility MMSE 
SP A. 
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Figure 3 . shows a further exemplary embodiment of an MMS network 
architecture. As regards the meaning of the elements shown in the 
Figure, reference is made to Figures 1 and 2. In the exemplary in 
accordance with Figure 3 the functionality of the connection node 
5 MMS RO A is integrated into the network element MMS RL A3 . This 
performs the central function of the MMS switching node. 

Figure 4 shows an exemplary embodiment of a network architecture in 
which sender and recipient make use of the MMS service of different 
MMS service providers and the MMS service providers in their MMS 

service environment have a number of MMS network elements available 
of which a number support a desired functionality. As regards the 
meaning of the elements shown in the Figure, reference is made to 
Figures 1 and 3. Elements shown on the user agent B side have the 
corresponding meaning. A user agent A (MMS UA A) would like in this 
exemplary embodiment, when sending an MMS to user agent B (MMS UA 
B) , to make use of what is known as a reply charging functionality. 
This means that it is prepared to accept the costs for a reply MMS 
from the recipient. To this end he compiles an MMS on his terminal 
(MMS UA A) , addresses it to recipient B, marks it with the reply 
charging identification and sends it via the interface MM1 to his 
network service provider MMS SP A. The MMS sent by the MMS UA A is 
designated the original MMS to enable it to be distinguished from 
the reply MMS sent later by the MMS UA B user agent. 

Each MMS, after reaching a network environment, is initially 
25 directed to the switching node MMS RO A or MMS RO B. Here the header 
fields are investigated for whether the MMS is to be relayed because 
of a specific functionality to a specific network element in the 
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network environment of the network service provider. In the present 
exemplary embodiment the switching MMS RO A finds a reply charging 
identification in the header field of the original MMS, at which 
point it forwards the MMS to an MMS network element which it knows 
5 supports this reply charging functionality. It is assumed that this 
is the case for MMS network element MMS RL A3 . The outstanding 
feature of the reply charging functionality applied for by the 
sender is that particular function-specific data, such as for 
example the reply deadline and the identity of the original MMS, are 
10 stored in the MMS network element until the deadline set by the 

sender has expired or the expected response MMS has arrived from the 
recipient of the original MMS. For this reason the reply MMS must 
also be processed by the same MMS network element MMS RL A3 as the 
original MMS . 

15 After the transmission of the original MMS to the network 

environment MMSE SP B of recipient B the original MMS first also 
arrives at the switching node MMS RO B for evaluation of the header 
field there. On the basis of the reply charging identification the 
MMS is relayed in the network environment MMSE SP B to a network 

20 element MMS RL B2 which supports the reply charging functionality. 
The further processing of the original MMS with reply charging 
identification is undertaken in the network element MMS RL B2 . There 
the function-specific data is stored until the deadline assigned by 
the sender has elapsed or the expected reply MMS has arrived from 

25 user agent B. 

After the delivery of the original MMS to the MMS UA B of the 
recipient the latter can reply to the original MMS, by itself 
compiling a new MMS on its terminal MMS UA B, addressing it to the 
recipient A, identifying it as the reply MMS and sending it via the 
30 interface MM1 to its MMS service provider MMSE SP B. The message is 
identified by means of an extra header field defined for this 
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purpose, in which the message ID of the original MMS is entered. 



This exemplary embodiment of reply charging describes a case in 
which a reply MMS arriving in a network environment may not be 
relayed to just any network element present in the network 
5 environment, but only to that element which was active when the 
original MMS was sent and knows about the function-specific 
peripheral conditions. This is also the case when all network 
elements support the specific functionality. In the present example 
of the reply charging the function-specific peripheral conditions 

10 are the deadline and the message identification. The connection 

nodes MMS RO A can enter a path entry for possible response MMS in 
each original MMS which leaves the network environment MMSE SP A. 
Preferably the switching node MMS RO B stores a path specification 
set in the network environment MMSE SP A until the arrival of a 

15 reply MMS or until the deadline expires. On arrival of a reply MMS 
the switching node must be able to read out this path specification 
and insert it again within the deadline. The database needed for 
storing this switching information is connected to the MMS switching 
node or integrated into it. 

20 With the present invention an original MMS is provided with a return 
path specification on exit from a network environment. This enables 
a specific network element in the network environment of an MMS 
service provider, for example the network element which has been 
active in the processing of the original MMS and has knowledge of 

25 the function-specific peripheral conditions, to be referenced on 

sending a reply MMS. Preferably a network element is accessed via an 
Internet protocol (IP) address. The Internet protocol address can 
also be determined from a specified Universal Resource Identifier 
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(URI) by evaluating the name of the host computer, known as the 
domain name system host name. The return path specification can also 
be an e-mail address. In this case it is also conceivable for the 
network element to be addressed via another means of identification. 

5 Figure 5 shows a schematic diagram of sending an original MMS with a 
reply charging identification in an MMS network architecture. As 
regards the meaning of the elements shown, reference is made to the 
description of Figures 1 to 4, with similarly named elements having 
the same meaning. MM1 and MM4 represent interfaces. In this 

10 exemplary embodiment all the information needed for the transport of 
an MMS as well as the supplementary information for the reply 
charging functionality is entered as information elements in short 
messages, i.e. what are known as abstract messages. Abstract 
messages involve blocks of information transmitted between two MMS 

15 units connected to one another, with each information block 

containing at least one information element. Abstract messages are 
explained in detail in Technical Specification TS 23.140 Version 
5.3. 0, Release 5, of the 3rd Generation Partnership Project (3GPP) . 

If a device involved in this exchange of data does not recognize an 
20 information element, the latter is relayed unchanged. Different 

information elements must be defined for the interfaces MM1 and MM4 . 
if only one new information element is defined and used at both 
interfaces, a return channel allocated by the connection node MMS RO 
A in the network environment B of the receiver could be relayed 
25 unchanged to user agent MMS UA B if the network service provider 

MMSE SP B cannot recognize these information elements. In this case 
the user agent MMS UA B, i.e. the recipient of the original MMS and 



WO 2004/006593 



PCT/DE2003/001946 



sender of the reply MMS, could attempt, possibly using the return 
path issued by the switching node MMS RO A, to send a response MMS 
to its MMS service provider MMSE SP B. This path specification is 
however only valid for network environment A and cannot be evaluated 
5 by network environment B. The corresponding compatibility problems 
can be resolved by defining different information elements for the 
interfaces MM1 and MM4 . 

Figure 5 shows a transmission of an original MMS from agent MMS UA A 
of sender A to agent MMS UA B of recipient B, with RC-Req standing 

10 for the reply charging identification and URI A3 (MM4) or URI B2 
(MM1 , B-side) for the references of the two network elements 
involved in the transmission. Tx stands for transmission and Rx 
stands for receiving and the distinction of the MMS network 
environment of the sender from that of the recipient. As regards the 

15 meaning of the elements shown, reference is made to the description 
of Figures 1 to 5 with similarly named elements having the same 
meaning. Switching node MMS RO B can either store the path 
specification of the MMS switching node MMS RO A until the reply MMS 
arrives in the memory M of the switching node MMS RO B or can 

20 transfer it to the user agent MMS UA B. 

If a reply MMS is returned by the user agent MMS UA B of the 
recipient to the network environment MMSE B (interface MM1 , B-side) 
with the specification of the return path previously transferred in 
the original MMS, the switching node MMS RO B, after evaluation of 

25 the return channel, can forward the reply MMS to the network element 
within the network environment B which supports the desired reply 
charging functionality and exhibits knowledge of the function- 
specific peripheral conditions. In the present exemplary embodiment 
this would be network element MMS RL B2, characterized by the 

30 reference URI B2 . The same principle applies to the relaying of the 
reply MMS from network environment B to network environment A via 
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interface MM4 . The return path for this interface is either 
transferred with the MMS UA B of the sender or read out from memory 
M in the switching node MMS RO B . A corresponding procedure is shown 
in Figure 6. In network environment A the switching node MMS RO A, 
5 after evaluating the return path, can forward the reply MMS to the 
corresponding network element which supports the desired reply 
charging functionality within the network environment A and has 
knowledge about the function-specific peripheral conditions. In the 
present exemplary embodiment this would be network element MMS RL 
10 A3, characterized by the reference URI A3. 

As already mentioned, Figure 6 shows an exemplary embodiment of a 
transmission of a reply MMS from MMS user agent MMS UA B to user 
agent MMS UA A. As regards the meaning of the elements shown, 
reference is made to the explanations for Figures 1 to 5, with 

15 similarly named elements having the same meaning. Furthermore RC-ID 
stands for the message ID of the original MMS received beforehand 
which identifies the sent MMS as reply MMS. URI B2 (MM1, B-side) or 
URI A3 (MM4) stand for the references of the network elements active 
during the transmission of the original MMS in the two network 

20 element environments involved. 

Figure 7 shows a flowchart for sending an MMS using the abstract 
messages described here. As already explained the abstract messages 
each contain at least one information element which is exchanged 
between the two entities involved. Figure 7 shows two user elements, 

25 i.e. an initiating user agent MMS UA A and a receiving user agent 

MMS UA B. The two user agents are connected to network elements MMS 
RL A or MMS RL B . An MMS is sent by user agent MMS UA A to network 
element MMS RL A for the interface MM1 on the sender side by means 
of a abstract message 1. Network element MMS RL A confirms the 

30 correct receipt of the MMS with abstract message 2 . An MMS is 
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transmitted between two MMS network environments (via the interface 
MM4) with abstract message 3 and is confirmed with abstract message 
4. For interface MM1 on the recipient MMS UA B side the following 
abstract messages are defined: The recipient is informed about an 
5 MMS which is ready for downloading with the aid of the abstract 

message 5 and this can be acknowledged with abstract message 6 . With 
abstract message 7 the recipient MMS UA B can initiate the 
downloading of an MMS available on the network element. The MMS is 
delivered from the network element MMS RL B to the user agent MMS UA 

10 B by means of abstract message 8 . Abstract message 9 serves both to 
confirm the correct transmission of the MMS with abstract message 8 
and also to inform network element MMS RL B whether the recipient of 
the MMS agrees to a reply being sent or not. This reply can be 
requested by the sender in advance, together with the sending of the 

15 MMS, in abstract message 1 and if necessary is transferred with 
abstract message 10 to the network environment of the sender and 
from there with abstract message 12 on to the user agent MMS UA A of 
the sender of the MMS. Abstract message 11 is used to send a 
confirmation . 

20 To enable what is known as a return path to be transmitted as 
described on the interfaces MM1 and MM4, two new information 
elements are defined, namely a transmit return path and a receive 
return path, with transmission or receipt identifying the network 
environment of the sender or the network environment of the 

25 recipient. To specify the return path on sending a reply MMS two 
further information elements transmit destination and receive 
destination are defined. 
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The new information element transmit return path is inserted into 
abstract message 3 . For enhanced convenience this new information 
element can also be inserted into abstract message 2, which also 
makes it possible for the sender to directly access a network 
5 element which has processed the original MMS that he sent, for 

example if he wants to recall or update this message later. The new 
return path information element is supplemented in abstract message 
8 and the new receive destination information element is used in 
abstract message 1. 

10 If the return path of the network environment A cannot be buffered 

in the network environment B and it is also to be sent with abstract 
message 8 to user agent MMS UA B and from there is to be returned in 
abstract message 1 together with the reply MMS to network 
environment B, abstract message 8 must be expanded by the new 

15 information element transmit return path and abstract message 1 must 
be expanded by the new information element transmit destination. 

Figure 8 shows a flowchart of as exemplary embodiment of the 
implementation of the present invention in accordance with the WAP 
(Wireless Application Protocol) standard for mobile radio terminals. 

20 WAP is an open standard for communication between mobile radio 

terminal and the Internet . To bridge the air interface between a 
mobile radio terminal supporting MMS and the WAP node point there is 
provision for the use of the WAP transfer protocol. Figure 8 shows 
an exchange of WAP messages between four entities involved, i.e. the 

25 MMS client MMS C A, the MMS network element MMS PR A, the MMS 
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network element MMS PR B and the MMS client MMS C B. The relevant 
messages are transmitted along the arrows indicated by the numbers 
20, 21 and 25. First a message transmission request 20 is sent by 
MMS C A to MMS PR A. This is followed by confirmation 21. Between 
5 MMS PR A and MMS PR B there is the Internet IPN. MMS PR B issues an 
MMS notification 22 which is answered by a notification 23 . As shown 
by arrow 24, there then follows a WAP data request command 24, which 
is answered by the MMS delivery 25. This is followed by a message 
transfer confirmation 26. On the sender side this can be relayed to 
10 MMS C A, as shown by arrow 27. 

Confirmation 21 is supplemented by header field transmit return 
path, to enable the return channel to be transferred after receipt 
of an original MMS to the MMS client of the sender, so that the 
latter has knowledge of which MMS network element (MMS PR) in the 

15 area of responsibility of an MMS service provider it should address 
in the event of a recall or exchange command or similar. MMS message 
25 is supplemented by the header field receive return path, with the 
aid of which the MMS client of the recipient is informed about the 
return path of that MMS network element in the area of 

20 responsibility of an MMS service provider, to which the reply MMS is 
to be returned for further processing. If necessary the transmit 
return path specification is also supplemented in this MMS message. 
However this is only necessary if this information is not buffered 
or cannot be buffered in the network environment B. The message 

25 transmit request 2 0 is expanded by the header field receive 

destination and if necessary also by the header field transmit 
destination for resolution of the path entries. This allows an MMS 
to be relayed explicitly to the network elements in the area of 
responsibility of the MMS service provider involved. Preferably the 

30 field values of the header fields are encoded in the MMS messages as 
text strings. 



In the exemplary embodiments explained here the present invention 
has been explained on the basis of the reply charging functionality, 
since the function-specific data needed here is only known in each 
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case to an MMS network element within a service area, which makes 
specifying a return path for smooth functioning of a service 
essential. The present invention is not however restricted to reply- 
charging functionality, but can for example also be applied to 
5 functionalities such as recalls and replacements of MMS already sent 
and similar functionalities in which the storage of function- 
specific data is essential for a smoothly functioning service. With 
these functionalities the option of explicitly accessing a network 
element is also required. 



